The operation of a computer system is controlled by a computer program or group of programs called the Operating System ("OS"). In early operating systems, such as UNIX, a computer user input commands to the OS using a command line interface ("CLI"). A typical CLI consisted of a prompt and cursor on the computer screen. The user could issue a command to the operating system by typing the name of a program or command and then pressing an "Enter" key to send this input to the OS. The OS would then process the command and respond accordingly.
Later, more advanced OSs were developed which utilized a graphical user interface ("GUI") in combination with a mouse or other form of pointing or selecting device. In GUIs, the mouse controls a cursor which typically is portrayed as an arrow on the computer screen. In addition, the computer screen is separated into different regions, wherein each region represents different aspects of the computer system like the OS or an application program. The user controls the computer system by using the mouse to move the cursor over a desired region and then selecting a desired operation.
Current state of the art GUIs utilize an object oriented design. The phrase "object oriented" refers to a programming and design method in which program elements are organized as groups of objects, objects are instances of classes, and multiple classes are linked by inheritance relationships. Each class has a set of attributes that define the purpose of that class within the computer system. The organization of the object classes is hierarchical and attributes may be shared and propagated either upward or downward in the hierarchy. For further explanation of object oriented programming and design, the reader is referred to Grady Booch, Object Oriented Design with Applications, pp. 25-74, 1991, which is hereby incorporated by reference.
In object oriented GUIs such as IBM's OS/2.RTM., objects are represented as bitmaps on the computer screen. The background object on which other objects are displayed is called the "desktop." A user manipulates objects by using the mouse to perform actions on them. For example, the user can use the mouse to press a button object or move a window object. This type of GUI is preferable because all objects of a particular type are either of the same class or related to each other. Thus, a user can control all of the objects of a particular type by using the same methods, e.g., pressing a button by clicking the mouse over it.
With the advent of object oriented GUIs also came object oriented developing environments ("OODEs"). OODEs are computer programs or groups of programs that allow a software developer to create object oriented programs. OODEs typically have a palette of objects with which the developer builds an application. Each object on this palette is different and serves as a template for the developer. A palette object's attribute settings are the default settings for that object. To use an object on the palette, the developer copies the object and places the copy in the application. The copy of the palette object is called the "derived object." The derived object has the same attribute settings as the original palette object.
Once the derived objects have been placed in an application, the developer can modify the attribute settings to specify the relationships between the objects. The behaviors of multiple objects can be linked together. For example, a "clear" button can be linked to a "file name" text field. The link can be set such that when the button is pressed, the text currently in the field is deleted.
In prior art OODEs, this link between objects is represented as a line or arrow drawn from a source object to a target object, called a "connection." The source end of the connection identifies an event which the source object can cause while the target end represents an action the target part can perform. Thus, the connection indicates that when the event occurs at the source object the target object is to perform the associated action.
The developer typically specifies the events and actions at the ends of connections by using a series of pop-up windows and menus listing all possible events for the source objects and all possible actions for the target object. For most objects, the developer frequently uses only a small subset of the available choices. Nevertheless, the developer is forced to choose from the complete list of menu choices each time objects are linked. As a result, developers get annoyed and frustrated by having to repeatedly perform this tedious and time consuming task.